01:02 anholt: valentine: recognize the error at https://gitlab.freedesktop.org/anholt/mesa/-/jobs/95696230#L434 at all? I've untarred my stack of rootfs and overlay, and all it's got is an empty dev/
07:33 glehmann: how do I disable the panfrost-t860 jobs in mesa because they are clearly not working for like half a day now?
07:35 glehmann: valentine: daniels: ^ fyi, because these are collabora runners
07:59 glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40399/diffs?commit_id=0156d086b336a8ff0ac49a0b0bb315d5a8e44be1 I guess this works
08:05 valentine: glehmann: yeah that does, but they're fixed now fwiw
08:23 pq: javierm, sure, and Y8 (in lack of Y4) would be semantically most appropriate.
09:04 bbrezillon: tzimmermann, mlankhorst, mripard: FYI, I'm currently testing the conflict resolution for the conflict caused by the merging of "drm/shmem-helper: Fix huge page mapping in fault handler" into drm-misc-fixes
09:04 tzimmermann: ok
09:04 mripard: bbrezillon: oh, awesome I was about to ask :)
09:05 bbrezillon: I just don't know of a way to do that upfront, unfortunately
09:05 bbrezillon: every time I have to go and push stuff through dim, to then fix the stuff in drm-tip, compile test, and push again
09:06 bbrezillon: which usuall means a 30min+ turnaround
09:07 bbrezillon: if you have suggestions to prepare things before pushing to the drm-misc-xx branch, I'd be happy to do that next time
09:07 mripard: I don't really have any, but also I don't mind a 30+ minutes turnaround if you're on top of it
09:07 mripard: and communicate about it
09:07 mripard: which you did
09:08 mripard: so there's a bit of disruption, but it's bound to happen from time to time and you're dealing with it perfectly
09:08 mripard: not sure there's something to fix
09:17 bbrezillon: mripard, tzimmermann: should be good now. Do we need to pass the conflict resolution to sfr before he reports it?
09:18 tzimmermann: bbrezillon, linux-next pulls drm-tip, i think
09:18 bbrezillon: tzimmermann: also, would be great if you could have a look at the version, to make sure I didn't mess up with the folio access tracking stuff
09:18 bbrezillon: tzimmermann: ah, good!
09:18 tzimmermann: where can i find it?
09:19 bbrezillon: drm-tip
09:19 mripard: bbrezillon: also, sfr doesn't handle linux-next anymore
09:20 tzimmermann: let me see
09:20 mripard: Mark Brown does now
09:23 bbrezillon: good to know :D
09:24 javierm: pq: formats are hard :) too many to chose from
09:25 bbrezillon: mripard, tzimmermann: BTW, we're gonna need a backmerge of the next -rc into drm-misc-next next week to properly fix the conflict and also add a fix for pfn_mkwrite on top
09:25 bbrezillon: I mean, next week or the following one, depending on when the fix I just pushed to drm-misc-fixes hits Linus' tree
09:26 tzimmermann: bbrezillon. ok
09:26 tzimmermann: the code looks good AFAICT
09:27 bbrezillon: thanks for checking!
09:28 pq: javierm, it's all grown organically rather than designed, and that's what it looks like.
09:38 javierm: pq: indeed
10:37 valentine: anholt: yes, that error isn't very helpful, but the issue was that the contents of the overlay were already present in the rootfs
10:37 valentine: removing those 3 dirs from the base rootfs fixes the issue: https://gitlab.freedesktop.org/Valentine/mesa/-/commit/993a9ad6551ea752dbd23e8537b3c2e9c91e8a99
10:38 valentine: btw the new trace tool looks awesome, and +1 for using overlays here
13:56 karolherbst: so looks like sin/cos works the same on nvidia and AMD and now I need a better name for fsin_amd...
13:57 karolherbst: could cheap out and call it fsin_amd_nv...
14:13 dj-death: karolherbst: lol, looks like it's similar on intel
14:13 karolherbst: yeah...
14:13 karolherbst: it's "similar" on other gens
14:14 karolherbst: I think we should come up with a naming scheme
14:14 karolherbst: and do the lowering in nir
14:14 dj-death: fsin_desktop
14:14 karolherbst: I've picked fsin_normalized_2_pi for AMD/NV
14:14 karolherbst: fsin_mdg would be fsin_normalized_1_pi
14:14 karolherbst: fsin_agx would be fsin_normalized_0_5_pi
14:14 karolherbst: maybe
14:14 karolherbst: dunno
14:15 karolherbst: I'll open up an MR soonish, because NVK does it in NAK and I want to move it to the nir side for better optimization
14:15 karolherbst: and might as well share the code that already exist
14:16 karolherbst: on nvidia we actually have fp16 support for it, that's why I'm even looking into this
14:23 karolherbst: ohh yeah, looks like Intel does it the same way
14:44 zmike: mareko: thoughts on deleting PIPE_BIND_SAMPLER_VIEW ?
15:15 mareko: zmike: ack
15:15 mareko: zmike: eeee no
15:15 mareko: zmike: is_format_supported needs it
15:16 zmike: hm
15:20 bbrezillon: tzimmermann: just sent a suggestion of a fix for the hangs caused by the pfn_mkwrite() addition
15:21 bbrezillon: I can't tell if that's correct, so, depending on whether we get MM maintainers to review or not, we might want to consider reverting this change...
15:21 bbrezillon: (this change == the addition of pfn_mkwrite)