20:09 <alyssa> anarsoul: yikes.. did not see how many places lima_resource.c depends on pixels vs blocks

20:10 <anarsoul> yeah, unfortunately it's not trivial to fix

20:10 <alyssa> given I don't even own utgard hw, I guess the alternative is to define the tiling routines to operate on pixels and then I don't need to touch lima at all

20:10 <alyssa> (and lima still gets the bugfix)

20:11 <anarsoul> alyssa: didn't I mention drm-shim? :)

20:11 <alyssa> you did, didn't I mention my laziness? :-p

20:11 <alyssa> also "doesn't crash" isn't the bar for correct here ;)

20:12 <anarsoul> I can test it (and probably spend an hour or two to fix it) if it doesn't crash

20:12 <alyssa> I see prior art in mesa for both transforming pipe_box to units of blocks (v3d) or not and being very careful when doing texture address calculations (freedreno)

20:13 <alyssa> I don't have a strong preference. But given lima already does freedreno style it's tempting to do the same in panfrost and stop bikeshedding

20:13 <anarsoul> alyssa: is there any reason not to keep it in pixels?

20:14 <alyssa> Mmh, it's not clear to me logically what it means for x/y/w/h to be unaligned (with respect to block size)

20:14 <alyssa> Maybe the spec forbids that?

20:15 <alyssa> Insisting on "integers in units of blocks" in the tiling routine prototypes makes it blatantly obvious that subblock access is illegal

20:15 <anarsoul> well

20:15 <anarsoul> not illegal

20:15 <anarsoul> they just get forcefully aligned

20:15 <anarsoul> :)

20:15 <alyssa> I shudder

20:16 <anarsoul> maybe just add assert to pan_tiling.c if x/y/w/h aren't aligned to block size and then align it in the drivers?

20:17 <alyssa> "The width and height of each sub-image must be a multiple of the block size for the format"

20:17 <alyssa> "Modifying compressed images along aligned block boundaries is possible"

20:18 <alyssa> I don't see anything in es3.2 spec about how unaligned access is supposed to work (silent alignment? error?)

20:19 <alyssa> ah here page 184 of the spec

20:19 <alyssa> INVALID_OPERATION if not a multiple of the block size

20:19 <alyssa> So assert sounds about right

20:19 <alyssa> I imagine vk is the same

20:21 <enunes> alyssa: CI is still not back up (I was still trying to improve the runtime a bit) but it kinda works, I had run your commits through it here: https://gitlab.freedesktop.org/enunes/mesa/-/pipelines/476327

20:21 <enunes> if you need to test it shortly, maybe pulling the CI enable commit for a quick run may help

20:24 <alyssa> enunes: ack

20:24 <alyssa> strongly considering picking the approach that involves no lima changes and no possible lima breakage 😅

21:59 <anarsoul> alyssa: let me run your rewritten MR through deqp...

22:02 <alyssa> warning: it's not even a little tested.

22:02 <anarsoul> tjat

22:02 <anarsoul> that's what deqp for :)

22:24 <alyssa> anarsoul: CI says panfrost is happy with the changes, you tell me if lima is

22:26 <anarsoul> alyssa: still compiling it on my rock64 :)

22:32 <alyssa> ah well yes

22:33 <anarsoul> alyssa: no new failures in deqp

23:22 <alyssa> anarsoul: woohoo!

23:22 <alyssa> it should also fix a piglit, should.

23:22 <anarsoul> we'll need enunes to confirm that

23:22 <anarsoul> :)

23:22 <alyssa> enunes: You have been paged :-p

23:22 <anarsoul> it's night time for him

23:23 <alyssa> ah yes timezones

23:23 <anarsoul> alyssa: btw there's no native s3tc support in utgard

23:23 <enunes> I happen to be around, I can rebase that CI branch

23:24 <anarsoul> so I'm not sure if there'll be any piglit fixes

23:24 <alyssa> anarsoul: ack

23:24 <alyssa> it should still fix a bug with texsubimage+etc1

23:24 <anarsoul> is it supported in panfrost?

23:25 <alyssa> dunno?

23:25 <anarsoul> well, you removed some s3tc-related failures in your change :)

23:25 <alyssa> The buggy case is doing glTexSubImage with a nonzero x/y start coordinate, if the format is a block compressed texture

23:25 <alyssa> it's not s3tc specific

23:26 <alyssa> I don't know if Piglit tests ETC1 + glTexSubImage + nonzero x/y start

23:28 <anarsoul> looks like panfrost indeed supports s3tc

23:28 <anarsoul> nice

23:29 <enunes> alyssa anarsoul: this should work: https://gitlab.freedesktop.org/enunes/mesa/-/pipelines/477255

23:31 <enunes> and then I should probably send the MR to enable it again, rather than prolonging the efforts to improve it while offline...

23:32 <anarsoul> enunes: you can just enable deqp for now if piglit isn't ready yet

23:33 <alyssa> panfrost piglit still isn't ready 🙃

23:33 <enunes> I think piglit is fine, but the boards timeout on dhcp every now and then which increase the runtime by about 3 minutes as it eventually works after some retries

23:34 <enunes> doesnt seem to be dhcp itself but looks like the nic thinks it sent dhcp requests, but none reach the dhcp server

23:34 <enunes> not a u-boot/firmware issue on my tests so far, maybe a linux driver issue but thats where I stopped troubleshooting

23:36 <enunes> static ip doesnt seem to help as the boards just dont have connectivity and fail to mount nfs

23:36 <enunes> so eh, it did work for months retrying that dhcp request a couple of times when it happened

23:37 <alyssa> for us, the piglit run itself is a mess

23:37 <alyssa> I guess it would be fine if we used a judicious skip list, but, eh

23:37 <alyssa> The compromise is to keep it as a manual job which someone triggers on interesting MRs to update expectations

23:38 <enunes> I saw some drivers do that, turning it into manual would be my fallback plan if piglit turns out to be flaky

23:40 <alyssa> gpu faults sometimes cause problems for other processes on panfrost

23:40 <alyssa> don't think too hard on what went wrong in the kernel for that ....

23:40 <enunes> I guess the tradeoff is that if some MR did regress piglit tests, the next person to manually trigger it would see issues that are not their fault?

23:40 <alyssa> so any faulting tests lead to random flakes

23:41 <alyssa> Yep

23:41 <alyssa> and if some MR fixes piglit tests the next to trigger would get unaccounted for UnexpectedPass's and would have to update the expectations separately

23:42 <enunes> in that case you send a standalone MR just to update the expectation lists?

23:43 <alyssa> yeah

23:43 <alyssa> or just toss the commit onto whatever MR, I have bad MR hygiene :-p

23:53 <anarsoul> I wish there was deqp for desktop gl2 :)

23:53 <anarsoul> piglit is a mess

23:54 <anarsoul> and piglit failures are often hard to debug

23:55 <icecream95> It seems that my original two-line commit did work on Lima (tested on Mali450) with no other changes. There were no Piglit tests that could've been useful here, so I had to s/DXT1/ETC1/ on arb_get_texture_sub_image-getcompressed