00:40 olivial: okay what does the 'first_ubo_is_default_ubo' flag actually mean?
00:41 olivial: nir_lower_uniforms_to_ubo doesn't actually put uniforms in UBO0 if there weren't any uniforms
00:41 olivial: so I guess it's "nir_lower_uniforms_to_ubo was run at some point"
00:41 olivial: is there a way to tell whether UBO0 is actually default?
00:43 mareko: UBO0 is always GLSL uniforms
00:45 olivial: hmm... what happens if there are no load_uniform instructions, but there are UBO blocks in the original shader
00:46 olivial: my reading of nir_lower_uniforms_to_ubo is that it will leave the first UBO from the shader in UBO0 in that case
00:46 olivial: oh wait... it will always make progress because it remaps the existing load_ubo instructions
00:46 olivial: I think I understand now
07:33 javierm: jfalempe: done
07:34 jfalempe: javierm: thanks ;)
14:53 zmike: kusma: have you managed to figure out that panfrost sync issue?
18:07 lumag: vignesh, robclark: DRM CI seems to be broken again. https://gitlab.freedesktop.org/drm/msm/-/jobs/75442773
18:07 lumag: https://gitlab.freedesktop.org/drm/msm/-/jobs/75442771
18:08 robclark: lumag: I think it was just never fixed after the gitlab migration... ci-fairy isn't a thing anymore
18:09 lumag: robclark, "nice" :-(
18:09 robclark: well, maybe it is fixed in drm-misc-next?
18:09 lumag: I picked up CI patches between msm tree and drm-misc-next
18:10 lumag: and it seems there is nothing on the ML.
18:10 robclark: hmm.. IIRC ci-fairy gets replaced with curl.. and maybe some other changes..
18:11 lumag: robclark, well... I hope Vignesh or Helen can fix that.
18:11 robclark: lumag: `[PATCH v1 3/3] drm/ci: uprev mesa`
18:12 robclark: replaces ci-fairy with s3_upload, which I guess is a wrapper around curl?
18:13 lumag: robclark, from March 28th?
18:13 lumag: Let's try that...
18:13 robclark: yeah
18:14 robclark: looks like it is at least intended to fix this... but I couldn't figure out where it applied cleanly when I wanted to test msm-fixes
18:14 lumag: It applied on my hacked up msm+CI-from-drm-misc-next tree
18:37 kusma: zmike: No, haven't been able to reproduce the issue yet, having some IO issues on my G57 board... :/
19:24 zmike: :/
19:41 kusma: zmike: OK, I think I reproduced it, and it seems... we're running out of memory after your series...
19:44 kusma: Yep...
19:51 kusma: Seems like it might be related to panfrost_batch::key
19:53 zmike: huh
19:53 zmike: well I just eyeballed it, so I'm not too surprised if something more subtle broke
19:53 zmike: feel free to post/push a fix
20:00 kusma: I don't have a fix
20:01 kusma: Very hand-wavy, but it kinda seems some refcounting is going wrong with util_copy_framebuffer_state() to me
20:30 zmike: seems strange that only panfrost would encounter that
20:48 kusma: Nah, I was off the mark. That bit seems to work fine. The problem is we get into an infinite recursion in pan_legalize_format