01:02anholt: 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:33glehmann: how do I disable the panfrost-t860 jobs in mesa because they are clearly not working for like half a day now?
07:35glehmann: valentine: daniels: ^ fyi, because these are collabora runners
07:59glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40399/diffs?commit_id=0156d086b336a8ff0ac49a0b0bb315d5a8e44be1 I guess this works
08:05valentine: glehmann: yeah that does, but they're fixed now fwiw
08:23pq: javierm, sure, and Y8 (in lack of Y4) would be semantically most appropriate.
09:04bbrezillon: 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:04tzimmermann: ok
09:04mripard: bbrezillon: oh, awesome I was about to ask :)
09:05bbrezillon: I just don't know of a way to do that upfront, unfortunately
09:05bbrezillon: 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:06bbrezillon: which usuall means a 30min+ turnaround
09:07bbrezillon: 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:07mripard: I don't really have any, but also I don't mind a 30+ minutes turnaround if you're on top of it
09:07mripard: and communicate about it
09:07mripard: which you did
09:08mripard: 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:08mripard: not sure there's something to fix
09:17bbrezillon: mripard, tzimmermann: should be good now. Do we need to pass the conflict resolution to sfr before he reports it?
09:18tzimmermann: bbrezillon, linux-next pulls drm-tip, i think
09:18bbrezillon: 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:18bbrezillon: tzimmermann: ah, good!
09:18tzimmermann: where can i find it?
09:19bbrezillon: drm-tip
09:19mripard: bbrezillon: also, sfr doesn't handle linux-next anymore
09:20tzimmermann: let me see
09:20mripard: Mark Brown does now
09:23bbrezillon: good to know :D
09:24javierm: pq: formats are hard :) too many to chose from
09:25bbrezillon: 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:25bbrezillon: I mean, next week or the following one, depending on when the fix I just pushed to drm-misc-fixes hits Linus' tree
09:26tzimmermann: bbrezillon. ok
09:26tzimmermann: the code looks good AFAICT
09:27bbrezillon: thanks for checking!
09:28pq: javierm, it's all grown organically rather than designed, and that's what it looks like.
09:38javierm: pq: indeed
10:37valentine: 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:37valentine: removing those 3 dirs from the base rootfs fixes the issue: https://gitlab.freedesktop.org/Valentine/mesa/-/commit/993a9ad6551ea752dbd23e8537b3c2e9c91e8a99 10:38valentine: btw the new trace tool looks awesome, and +1 for using overlays here
13:56karolherbst: so looks like sin/cos works the same on nvidia and AMD and now I need a better name for fsin_amd...
13:57karolherbst: could cheap out and call it fsin_amd_nv...
14:13dj-death: karolherbst: lol, looks like it's similar on intel
14:13karolherbst: yeah...
14:13karolherbst: it's "similar" on other gens
14:14karolherbst: I think we should come up with a naming scheme
14:14karolherbst: and do the lowering in nir
14:14dj-death: fsin_desktop
14:14karolherbst: I've picked fsin_normalized_2_pi for AMD/NV
14:14karolherbst: fsin_mdg would be fsin_normalized_1_pi
14:14karolherbst: fsin_agx would be fsin_normalized_0_5_pi
14:14karolherbst: maybe
14:14karolherbst: dunno
14:15karolherbst: 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:15karolherbst: and might as well share the code that already exist
14:16karolherbst: on nvidia we actually have fp16 support for it, that's why I'm even looking into this
14:23karolherbst: ohh yeah, looks like Intel does it the same way
14:44zmike: mareko: thoughts on deleting PIPE_BIND_SAMPLER_VIEW ?
15:15mareko: zmike: ack
15:15mareko: zmike: eeee no
15:15mareko: zmike: is_format_supported needs it
15:16zmike: hm
15:20bbrezillon: tzimmermann: just sent a suggestion of a fix for the hangs caused by the pfn_mkwrite() addition
15:21bbrezillon: 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:21bbrezillon: (this change == the addition of pfn_mkwrite)
15:28bbrezillon: hm, looks like Mark got the same conflict, so he's not using drm-tip
15:29bbrezillon: mripard, tzimmermann: any clue where I can find the proper resolution to share with him (rerere?)
15:39bbrezillon: never mind, found a way to get that diff from the merge conflict
15:39bbrezillon: *merge commit
15:41tzimmermann: oh! so they do pull the drm-misc trees
15:41tzimmermann: s/trees/branches
15:47anholt: valentine: thanks for the help! would not have figured that out.
16:02valentine: no problem, we should probably leave a comment about this in lava-submit.sh
16:06anholt: valentine: done
16:09valentine: cool
16:21karolherbst: so what are the details around fp_math_ctrl and nir_algebraic.AlgebraicPass? I'm seeing "b->fp_math_ctrl = sincos->fp_math_ctrl" done inside ac_nir_lower_sin_cos and was wondering if that means it has to be a proper nir pass or is there a way to model that through nir_algebraic.AlgebraicPass?
16:25glehmann: nir_search takes the union of all fp_math_ctrl flags from the matched instructions and applies it to new ones
16:25glehmann: so ac_nir_lower_sin_cos can just be an algebraic pass
16:38karolherbst: okay, cool
16:38karolherbst: in NAK we disabled denorm flushing on the pre factor tho.. I wonder how much that matters
16:40pendingchaos: ac_nir_lower_sin_cos isn't an algebraic pass because it seemed excessive for a pass which just replaced single instructions with two instructions
16:40pendingchaos: not because what it was doing was inexpressible as an algebraic pass
16:41glehmann: if I had to guess denorm flushing for the factor doesn't matter because the special function unit flushes them anyway
16:41glehmann: at least that's how it works on amd
16:41karolherbst: oh yeah...
16:41karolherbst: same on nvidia
16:42karolherbst: apparently tanh doesn't flush denorms, but that's not even wired up at all in nir
16:42glehmann: amd will have it too in the next gen
16:43karolherbst: tanh? I haven't checked if Vk/GL have it at all, but if it's already there, I might already wire it up
16:44karolherbst: nvidia seems to have it since Turing, so that's quite a long time ago already
16:44glehmann: glsl and spirv have the kitchen sink
16:44glehmann: but tanh is used for ML so of course every vendor needs it now
16:44karolherbst: ohh I see
16:44karolherbst: it's lowered mhh
16:45karolherbst: well might as well wire it up 🙃
16:45karolherbst: I should check how many shaders are hitting it...
16:46karolherbst: ohhh..
16:46karolherbst: I think I've seen this pattern..
16:48glehmann: but yeah I agree with pendingchaos that an algebraic pass with two patterns is excessive
16:48glehmann: imo either move the ac pass to common code, or put the patterns in nir_opt_algebraic with a new nir option
16:48karolherbst: I can also just move the pass.. but now I already did the work
16:48karolherbst: ohh yeah.. maybe a new option is fine
16:49karolherbst: okay.. I'm seeing games hitting tanh
16:49karolherbst: guess I get side tracked even more this week
20:06anholt: valentine: looks like the kernel on arm64 at least doesn't have zstd support for zram, so we don't have any swap. this may relate to some of our OOM issues we've had recently.
20:08anholt:dreams of a day when oomkiller knows about private uma BO memory allocation
20:18HdkR: Gotta get that zstd compressor config option enabled :D
20:39valentine: hm yeah good catch, I'll take a look later
20:39mareko: the oom killer not knowing about TTM memory usage is a known exploit
20:39mareko: Christian had a fix for it but it was rejected
23:54cssushiman: I have a queston - Why doesn't OpenGL have a command buffer object? Is there some software architexture reason for this, or is it a different reason?
23:55cssushiman: (ie: It wouldn't be beneficial to implement)
23:57cssushiman: *e.g.
23:59HdkR: Display lists are back on the menu!