06:38 <narmstrong> I’ll analyze the log more closely, but since I’m a total noob in OpenGL it won’t help

06:39 <narmstrong> alyssa: apitrace should work right ?

06:39 <narmstrong> At least to know what was submitted to Mesa

09:52 <narmstrong> Seems to be the first JOB_TYPE_TILER that fails for this frame, the only differences with the previous frame are the last words of the mali_uniform_buffer_meta ubuf, there are all at 0 instead of stuff like 0xbf800000, 0x3f800000, 0x3f800000, 0x3f800000 for all job types (VERTEX and TILER)

09:56 <tomeu> guess it would be cool to be able to just change that and rerun :)

10:50 <narmstrong> well, I have no idea of what's wrong :-]

10:55 <tomeu> maybe try changing those zeroes to the values you see in the other frames?

12:52 <tomeu> narmstrong: here, fence is always NULL in drm_gem_fb_prepare_fb

12:53 <tomeu> and the fence-related code doesn't seem to be run in kbase

12:53 <tomeu> probably some config missing or such

12:58 <tomeu> with MALI_DMA_FENCE=y in the config file, the code is at least being run :)

13:01 <tomeu> with that, and a change in panfrost, I get a fence in drm_gem_fb_prepare_fb, but no visible difference

13:15 <tomeu> fences seem to work fine, the rendering is very fast and when we submit the BO for display, the rendering has long finished

13:15 <tomeu> wonder if something needs to happen before anything other than the GPU can access the rendered content

13:15 <tomeu> some cache flushes, etc

13:21 <tomeu> hmm, it's looking much better with BASE_JD_REQ_CF

13:22 <tomeu> still not correct though

13:26 <tomeu> that seemed to be a coincidence, now it looks as before

13:29 <tomeu> ok, got it to display correctly now

13:30 <tomeu> removing BASE_JD_REQ_SKIP_CACHE_END in the first atom gets the rendering right

13:30 <tomeu> wonder why though, as the second atom didn't have it already

13:31 <tomeu> beautiful cube :)

13:50 <tomeu> forcing has_egl_buffer_age to false in weston solves the cursor problem

14:02 <tomeu> alyssa: any ideas of where could the problem be with weston's optimization to only render what has changed in a BO?

14:02 <tomeu> could it be that we clear the whole FBO at the start of each render or so?

14:26 <tomeu> have pushed two fixes to my winsys branch

14:26 <tomeu> kmscube runs now without visible problems, and without warnings

14:27 <tomeu> weston still has the problem with the buffer being blacked out any time we render anything

15:00 <narmstrong> tomeu: do you still have a gpu fault ?

15:00 <tomeu> narmstrong: nope

15:00 <narmstrong> tomeu: I will try your 2 fixes and look the diff with your winsys branch

15:10 <tomeu> narmstrong: this could also help: https://gitlab.freedesktop.org/tomeu/mali_kbase/commit/3eae495ac64fd0d0f8d7b547d249202d52e9b7f1

16:08 <alyssa> narmstrong: Maybe? I've never used apitrace with Panfrost, so I don't know what it requires.

16:08 <alyssa> tomeu: We do clear the whole FBO at the start, yeah

16:08 <narmstrong> Well it works fine but doesn’t give much info

16:09 <alyssa> There are ways to do partial rewrites like Weston wants, but it's tricky (lima ran into this)

16:09 <narmstrong> Yeah Lima solved this but it needs some work

16:09 <alyssa> (it requires implementing some additional GL extensions. It's nothing we couldn't do, but I haven't been focusing too much on perf yet)

16:10 <alyssa> For Weston-backed-by-X, it seems to disable those partial writes on panfrost

16:10 <narmstrong> alyssa: with apitrace you could replay kmscube (or other) calls with your setup

16:10 <alyssa> narmstrong: Oh, hm, that might be useful actually, thank you :)

16:11 <narmstrong> alyssa: I’ll regenerate a trace so you don’t need to bother building and running it ^^

16:14 <alyssa> Okey dokey!

23:56 <anarsoul|2> why do you need it?