00:39 <anarsoul> yuq825: looks like there's some issue with reusing plb pp stream :\

00:40 <anarsoul> I get weird misrendering in X11 with it enabled

00:52 <anarsoul> but it's fixed if I call lima_generate_pp_stream() after retrieving pp_stream bo from cache

00:58 <anarsoul> OK, fixed it

00:58 <anarsoul> we also need to add fb params to pp stream key

01:28 <yuq825> I get this a bit more thinking, we are trading CPU time building pp_stream for GPU time and memory bandwidth executing tasks, a bound box pp_stream cache trade some GPU time for CPU time back because the bound box is not accurate, the problem is the bound box accuracy (we may even use a pp_stream whose bound box can cover current task's bound box)

01:29 <yuq825> that how to choose bound box

01:30 <yuq825> how to choose existing pp_stream in the cache

01:31 <yuq825> maybe a coverage rate of current task's damage area can be used to choose the pp_stream in the cache

01:32 <yuq825> not exact bound box match

01:36 <yuq825> when the rate is low, we may re-build pp_stream

01:36 <yuq825> accurately

01:36 <anarsoul> yuq825: it just gets too complicated, so I'm not sure we'll get much of out it

01:40 <yuq825> it's OK we just have accurate bound box based pp_stream cache first, we need it anyway, we may optimize it by this idea in the future

01:41 <yuq825> just remind this bound method does not only have memory trade off, also GPU time trade off

02:27 <anarsoul> yuq825: yeah, I guess it's impossible to find perfect solution here

02:29 <anarsoul> I think bounding box should work well for desktop when usually it's a single window that gets updated

02:36 <anarsoul> yuq825: btw please merge your multi-job MR

02:36 <anarsoul> it seems to be stable and since it's quite massive and reworks a lot it would be nice to get it merged

02:36 <anarsoul> otherwise there will be conflicts with other MRs

02:37 <yuq825> ok, I'll merge your kernel fix first, then this MR

17:26 <rellla> anarsoul: i am one step further with dEQP-GLES2.functional.depth_stencil_clear.depth_stencil_masked :)

17:26 <rellla> have to stop thinking now, but this is what i found out:

17:30 <rellla> i logged stencil values. so let's say we have 0x67 as the stencil value after the last clear, which is the last action that writes stencil values

17:32 <rellla> https://github.com/KhronosGroup/VK-GL-CTS/blob/master/modules/gles2/functional/es2fDepthStencilClearTests.cpp#L376 does the tests and writes the value to RGBA if the test succeeds (if LEQUAL)

17:34 <rellla> so the (stencil) value i get in the resulting image is always the ndx-1 one, but it should be the ndx value instead

17:35 <rellla> i will think about that later, but maybe you have an idea in the meantime. maybe we use the wrong rsw for drawing or there is some off-by-one issue somewhere ...

17:39 <rellla> to complete the number example: if stencil value to test again is 0x67, we test 0x46 with LEQUAL which succeeds and is written to the image

17:40 <rellla> the next is 0x55 which should also succeed, but that one and the following ones of course do not succeed or aren't written to the image as G value